home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Games of Daze
/
Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso
/
x2ftp
/
msdos
/
formats
/
vicar2.txt
< prev
next >
Wrap
Internet Message Format
|
1991-06-26
|
15KB
From baalke@kelvin.jpl.nasa.gov Thu Jun 27 16:17:48 1991
From: baalke@kelvin.jpl.nasa.gov (Ron Baalke)
Newsgroups: comp.graphics
Subject: VICAR
Keywords: VICAR, JPL
Date: 26 Jun 91 13:44:38 GMT
Reply-To: baalke@kelvin.jpl.nasa.gov
Organization: Jet Propulsion Laboratory
News-Software: VAX/VMS VNEWS 1.3-4
Nntp-Posting-Host: kelvin.jpl.nasa.gov
At then end of this posting is a detailed description of the VICAR format
used by the Image Processing Lab at JPL. This will give people the ability to
write software on other computer platforms to read and display VICAR images,
like the Magellan images I've recently uploaded to Ames.
Also, I've compiled a list of software that will currently display images
in the VICAR format. If you know of any other programs that should be on the
list, then let me know, and I'll maintain an updated list.
o VICAR (VAX/VMS).
The image processing program used at JPL. Has been under continuous
development since the 1960's. Available from the Computer Software
Management and Information Center (COSMIC) for $4000 and requires a
license agreement. Contact COSMIC at the following for more details:
COSMIC
The University of Georgia
382 East Broad Street
Athens, GA 30602
Telephone: (404) 542-3265
Email: cosmic@uga.bitnet (bitnet)
service@cossack.cosmic.uga.edu (internet)
o IMDISP (IBM PC).
Written by myself and Mike Martin at JPL, and Archie Warnock at Goddard
Space Flight Center. Available via anonymous ftp at ames.arc.nasa.gov
[128.102.18.3] in the pub/SPACE/SOFTWARE directory, under the file
imdisp56.zip. IMDISP is on the GRIPS 2 CDROM, and can also be obtained
free from the National Space Science Data Center (NSSDC) at the Goddard
Space Flight Center:
National Space Science Data Center
Request Coordination Office
Goddard Space Flight Center
Code 633
Greenbelt, MD 20771
Telephone: (301) 286-6695
Email address: request@nssdca.gsfc.nasa.gov
Incidently, this is also the same place you can get the Voyager and
Magellan CDROMs.
o PixelPusher (Macintosh).
Written by Dan Stanfill at JPL. Available on the GRIPS 2 CDROM, and I'm
working on making it available via anonymous ftp.
o xloadimage (Sun).
Written by Herr Frost. Available via anonymous ftp at
export.lcs.mit.edu [18.30.0.238] in the contrib directory. The patches
to support VICAR are in a separate file at convex.com [130.168.1.1] and
are in pub/xl.3.0.1.patches.Z. Anthony Datri wrote the VICAR patches.
*************
___ _____ ___
/_ /| /____/ \ /_ /| Ron Baalke | baalke@kelvin.jpl.nasa.gov
| | | | __ \ /| | | | Jet Propulsion Lab |
___| | | | |__) |/ | | |__ M/S 301-355 | "Imagination is more
/___| | | | ___/ | |/__ /| Pasadena, CA 91109 | important than knowledge"
|_____|/ |_|/ |_____|/ | Albert Einstein
===========================================================================
VICAR2 IMAGE FILE FORMAT
1 Introduction
This document describes the format of a simple two-dimensional
VICAR2 image and the attached label.
2 VICAR2 File Format
A VICAR2 image file in its simplest form is a file with fixed-length
records containing binary data and an ASCII label. The label takes up
one or more records at the beginning of the file, and is further
described in section 3 below. The image data begins on the next record
boundary after the label. There is one record per image line, and the
number of bytes in a record is equal to the number of bytes in one image
line. The image data can be any one of the following data types,
indicated by a keyword in the image label:
BYTE: 8 bits = VAX byte
HALF: 16 bits = 2 bytes = VAX word = Fortran INTEGER*2
FULL: 32 bits = 4 bytes = VAX longword = Fortran INTEGER*4
REAL: 32 bits = 4 bytes = VAX longword = Fortran REAL*4
DOUB: 64 bits = 8 bytes = VAX quadword = Fortran REAL*8
COMPLEX: 64 bits = 8 bytes = VAX quadword = Fortran COMPLEX*8
3 VICAR2 Label Format
The VICAR2 label is in the form of an ASCII character string,
beginning at the first byte in the first record in the file. The label
may take up one or more records at the beginning of the file. If the
character string does not completely fill the final label record, the
remaining bytes in the record are set to the ASCII null value,
hexadecimal 00.
In some cases there may be an additional label record at the end of
the file, following the image data. This is indicated when the keyword
EOL has the value 1 (see description of keywords below).
3.1 The Keyword=Value Format
The label uses the KEYWORD=VALUE format for storing information
about the image. A list of standard keywords is given in section 3.3.
The maximum length of a keyword is 8 characters. A keyword is written
in all capital letters and is followed by an equals sign (=), which is
in turn followed by the value for the keyword. There are no spaces on
either side of the equals sign. The value is followed by one or more
spaces, in order to separate one KEYWORD=VALUE pair from the next. Here
is an example of one label item following another:
RECSIZE=1024 NL=1324
A keyword value may be one of four data types:
INTEGER A positive or negative integer including 0 which
does not contain a decimal point.
REAL A positive or negative number with a decimal
point and, optionally, an exponential (E+06, for
instance).
DOUBLE A real number with enough digits to make it
double-precision.
STRING A string delimited by single quotation marks (')
containing any printable ASCII characters and
spaces EXCEPT the single quotation mark. The
maximum length of a string is 512 characters,
and the minimum length is 1 character.
The first keyword in the label is always LBLSIZE, which specifies
the total number of bytes in the label, including any null bytes at the
end. Thus LBLSIZE will always be a multiple of the file's record size.
3.2 Two Parts of a VICAR2 Label
A label has two sections, the system label items and the history
label items. History label items are added to the label during
processing with VICAR software. It is possible for a label to contain
no history label items. If history label items do exist, they always
occur at the end of the label, following the last system label item.
The beginning of the history label section is marked by the occurrence
of the keyword TASK.
Thus, the system section of the label begins with the keyword
LBLSIZE, and ends in one of these three ways:
o with the appearance of the keyword TASK, which marks the
beginning of the history section of the label, OR
o with the appearance of an ASCII null value, hexadecimal 00, which
marks the end of the VICAR2 label (in which case there are no history
label items), OR
o after the number of characters specified by LBLSIZE (in which
case there are no history label items).
3.3 Standard Label Keywords
Here is a table of standard VICAR2 label keywords, divided into
system label items and history label items. Those marked with an
asterisk (*) are required to be present in order for the VICAR image
processing software to be able to process the label. LBLSIZE will
always be the first keyword in the label. The other system keywords may
follow in any order.
STANDARD VICAR2 LABEL KEYWORDS
SYSTEM LABEL ITEMS
KEYWORD TYPE MEANING
LBLSIZE* integer The length in bytes of the VICAR
label, including null bytes at the
end.
BUFSIZE* integer The default blocksize used when the
file is written to tape.
DIM integer The dimension of the file (for flat
files, always 2).
EOL integer EOL=1 indicates that an end-of-file
label exists. In most cases EOL=0;
i.e., there is no end-of-file label.
FORMAT* character The data type of a sample. Valid
values are: BYTE, HALF (16-bit
integer), FULL (32-bit integer), REAL
(32-bit floating-point), DOUB (64-bit
floating-point) and COMPLEX (2 32-bit
floating-points).
HOST character Type of host computer. The only
current legal value is 'VAX-VMS'.
INTFMT character The integer format for the file. The
only current legal value is 'LOW'.
N1 integer Same as NL for simple files.
N2 integer Same as NS for simple files.
N3 integer Same as NB for simple files.
N4 integer Always 0 for simple files.
NB integer The number of bands. For simple
files, always 1.
NBB integer Number of bytes in the binary prefix
to each line. Always 0 for simple
files.
NL* integer The number of lines in the image.
NLB integer The number of lines of binary header.
Always 0 for simple files.
NS* integer The number of samples per image line.
ORG character The organization of the file. For
simple files this is always BSQ (band
sequential).
REALFMT character The real format for the file. The
only current legal value is 'VAX'.
RECSIZE* integer The number of bytes per record; i.e.,
NS*LEN, where LEN is the number of
bytes per sample as follows:
FORMAT: LEN:
BYTE 1
HALF 2
REAL,FULL 4
DOUB,COMPLEX 8
HISTORY LABEL ITEMS
KEYWORD TYPE MEANING
DAT_TIM character The date and time the program was run.
The format is DOW MON DD HH:MM:SS
YYYY, where
DOW = day of week (Mon, Tue, Wed,
etc.),
MON = month (Jan, Feb, Mar, etc.),
DD = day of month,
HH:MM:SS = hours, minutes, seconds,
YYYY = year.
An example of a date and time in this
format is 'Mon Jan 11 21:51:55 1990'.
TASK character The name of a VICAR program that has
processed the file's data.
USER character The identifier of the user that
invoked the program represented by the
preceding TASK keyword.
The history label section may also contain other keywords that are
specific to the program that was run. These are sometimes called user
labels. They are informational only; they are not interpreted by VICAR
software, but they are copied from input file to output file with the
other label keywords.
*******************
From charliep@hpcvra.cv.hp.com. Thu Jun 27 16:18:19 1991
From: charliep@hpcvra.cv.hp.com. (Charles Patton)
Newsgroups: comp.graphics
Subject: Re: VICAR
Date: 27 Jun 91 01:52:45 GMT
Organization: Hewlett-Packard Co., Corvallis, OR, USA
For Mac users:
I have found that NCSA Image does a beautiful job displaying the
VICAR images with no special preparation other than noting the
height and width (given in human readable form at the start of
the file.) I highly recommend it for this purpose.
A Public Thank You:
I wish to thank Ron Baalke for making the Magellan images available.
These truly spectacular images have strongly rekindled my interest both
in digital image processing and in planetary imaging. Having watched the
Voyager Jupiter encounter with the Stony Brook group, and the Saturn
encounter from the Hansen planetarium, I was shocked to note how interest
has flagged over the intervening years. I'm sure that these images with
serve to stir both the scientific and general public interest in
planetary imaging missions.
In addition to all these, the Magellan images serve as ideal test cases
for inverse-Muhlemann-shading (shade-to-shape) experiments.
Thanks again.
Charlie Patton
*******************************************************
** Charles M. Patton **
** **
** charliep@cv.hp.com **
** the usual disclaimers apply **
*******************************************************
From datri@convex.com Thu Jun 27 16:20:35 1991
From: datri@convex.com (Anthony A. Datri)
Newsgroups: alt.graphics.pixutils
Subject: Re: VICAR
Keywords: VICAR, JPL
Date: 27 Jun 91 01:28:42 GMT
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Nntp-Posting-Host: beak.convex.com
> o xloadimage (Sun).
Anything reasonable that has X libraries, really.
> Written by Herr Frost.
Herr's a title that I gave in a mail message. Jim's his name, and xloadimage
is a fine piece of work for which he deserves much credit. My additions are
largely a peopen() and a bunch of strstr() calls 8^).
The patches in the mentioned archive are a little raw -- Jim should merging
them in [the important ones, at least] in an upcoming release. That archive
also includes a slightly modified copy of the uncompression program from
the Voyager CD-ROMs. Xloadimage will use that program to filter a Huffman-
encoded PDS file, as found on the Voyager CD's, to a straight VICAR file,
which it then interprets.
Rawtopgm, from the pbmplus suite, can digest VICAR files when fed the
appropriate arguments.
--
Use your wheels: that is what they are for.
datri@convex.com
